home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 5292 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.0 KB
  1. Path: ix.netcom.com!netnews
  2. From: miker3@ix.netcom.com (Mike Rubenstein)
  3. Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2,comp.lang.eiffel
  4. Subject: Re: Undefined behavior? on type conversion, was: Re: Hungarian notation
  5. Date: Sat, 03 Feb 1996 15:21:34 GMT
  6. Organization: Netcom
  7. Message-ID: <31137427.133220928@nntp.ix.netcom.com>
  8. References: <30C40F77.53B5@swsbbs.com> <4d2ok0$69s@beach.and.nl> <4er2qo$h2s@galaxy.ucr.edu> <31118641.6802368@nntp.ix.netcom.com> <4eurpq$b75@news.xmission.com>
  9. NNTP-Posting-Host: ix-dc11-06.ix.netcom.com
  10. X-NETCOM-Date: Sat Feb 03  7:21:26 AM PST 1996
  11. X-Newsreader: Forte Agent .99c/16.141
  12.  
  13. tknarr@xmission.com  ( Todd Knarr ) wrote:
  14.  
  15. > In <31118641.6802368@nntp.ix.netcom.com>, miker3@ix.netcom.com (Mike Rubenstein) writes:
  16. > >> : |> Repeating the quote from ISO 6.2.1.2
  17. > >> : 
  18. > >> : |>     When a value with integral type is demoted to a signed integer
  19. > >> : |>     with smaller size or an unsigned integer is converted to its 
  20. > >> : |>     corresponding signed integer, if the value cannot be 
  21. > >> : |>     represented the result is implementation defined.
  22. > 
  23. > >Consider a machine with 8 bit char and the expression
  24. > >
  25. > >    (char) 256
  26. > >
  27. > >Here we have correct syntax and correct data.  The standard says that
  28. > >this converts the number 256 to a char.  I believe I have a right to
  29. > >assume that this will be done.
  30. > 
  31. > Except that 6.2.1.2 says you can't assume that. Your particular
  32. > implementation may let you assume that, but the standard doesn't
  33. > require it to. On machines with the capability of extracting the
  34. > low-order bits the reasonable thing to do would be to fill in the
  35. > char with the low-order byte ( 0 in your example ), but the
  36. > standard doesn't say the machine has to have that capability, or
  37. > that the implementation has to excercise it, or that the implementation
  38. > has to be reasonable. As I asked before, do you think that, on a
  39. > machine where the natural hardware response to your example would be
  40. > a machine check and system halt, the committee intended to require
  41. > that the compiler insert a range check before every such conversion?
  42. > 
  43. > As for "result" vs. "behavior", while I don't have the standard in
  44. > front of me I believe that in the case of the ++ and -- operators the
  45. > side-effect increment and decrement is also referred to as a result.
  46. > If that is so, then their use of "result" doesn't rule out side-effects
  47. > in the conversion, which can be anything since the implementation gets
  48. > to define them.
  49. > 
  50. > Can you tell I tend to read the standard conservatively? I've been
  51. > burned once too often by assuming things that weren't explicitly
  52. > spelled out.
  53.  
  54. No, I can't tell that you read the standard conservatively.  You seem
  55. to be adding things that just aren't there.  You're saying that
  56. although the standard says that a construction converts one value to
  57. another and I use the construction correctly, with correct data, the
  58. implementation is not required to convert one value to the other and,
  59. in fact, is not required to even execute later instructions.
  60.  
  61. To make things perfectly clear, I believe that the standard requires
  62. this of a conforming implementation even if the underlying hardware
  63. does not directly support it.
  64.  
  65. The standard does not say that a machine must have the ability to do
  66. multiplication either.  That doesn't mean that an implemenation can
  67. simply give an exception if you do a multiplication -- it must handle
  68. it in software since the standard requires a C implementation be able
  69. to do multiplication.
  70.  
  71. I'm afraid that I can't find where the standard refers to the
  72. side-effect of incrementing.  Of course the standard is pretty large
  73. and I'm afraid I don't have the time to check it completely.  6.3.3.1
  74. clearly uses the word "result" only to refer to the value:
  75.  
  76.     The value of the operand of the prefix ++ operator is 
  77.     incremented.  The result is the new value of the operand after
  78.  
  79.     incrementation.
  80.  
  81. Perhaps your memory is faulty.  I'd suggest getting a copy of the
  82. standard and using that, rather than your memory, to justify your
  83. position.
  84.  
  85.  
  86. Michael M Rubenstein
  87.